You are requesting one (string constant in MS SQL), but you might need something else. The reason I say this is because you pointed out a few hints at your final goal, which apparently uses the same IN statement in several stored procedures.
The biggest clue in the last sentence:
I tried to pass this line as a parameter, so I could manage it from one point in my application but the stored procedure did not like it.
Without the details of your SQL scripts, I will try to use some psychic debugging techniques to find out if I can bring you to the point that I believe that this is your actual goal and not necessarily your stated goal.
Given that your stored procedure "did not like" when you tried to pass the string as a parameter, I assume that the string was just a limited list of values, for example, "10293, 105968, 501940" or "Juice, Milk, Donuts" (not pay attention to the actual values of the list - the important part is the delimited list). And your SQL might look something like this (again, ignore specific names and focus on the general concept):
SELECT Column1, Column2, Column3 FROM UnknownTable WHERE Column1 IN (@parameterString);
If this roughly describes the path you were trying to take, you will need to rethink your approach. Using the regular T-SQL statement, you cannot pass a string of parameter values to the IN clause - it just does not know what to do with them.
There are alternatives, however:
Dynamic SQL - you can create the entire SQL statement, parameters and all, then execute this in the SQL database. Perhaps this is not so. you are trying to reach as you move the script to the procedure store. But it is listed here for completeness.
Value table - you can create a table with one column that contains specific values that you are interested in. Then your saved Procedure can simply use the column from this table for the IN clause). Therefore, Dynamic SQL does not exist. Since you indicate that the values are unlikely to change, you just need to populate the table once and use it everywhere appropriate.
String Parsing to output a list of values - you can transfer the list of values as a string, then implement the code for analyzing the list into the table structure on the fly. An alternative form of this technique is to pass an XML structure containing values and use MS SQL Server XML functionality to retrieve the table.
Define a table-value function that returns the values to use - I have not tried this one so that I might be missing something, but you should be able to define the values in the table-value function (possibly using a bunch of UNION statements or something), and call this function in the IN section. Again - this is an unverified proposal and will be required to work out to determine this feasibility.
I hope this helps (assuming I guessed about your underlying hassle).
For future reference, it would be very helpful if you included an SQL script showing the table structure and the logic of the stored procedure, so that we can see what you were actually trying to do. This will greatly increase the effectiveness of your responses. Thanks.
PS Link to String Parsing actually includes a large number of methods for transferring arrays (for example, lists) of information to stored procedures - this is a very good resource for this kind of thing.